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Report  on  ORF  PnP  Symposium  Held  on  June  6-7,  2005 
Award  Number  W81XWH-05-2-0070 


Introduction 

Healthcare  -  especially  the  operating  room  environment  -  does  not  have  standardized  medical 
device  control  and  communication  systems.  As  a  result,  many  self-evident  improvements  - 
such  as  seamless  data  communication,  medical  device  integration,  remote  device  actuation, 
and  distributed  closed-loop  control  systems  -  have  been  precluded,  and  safety  and  economic 
benefits  have  not  been  realized.  Funding  was  sought  for  a  symposium  to  continue  the  process 
of  defining  technical  and  clinical  requirements  for  a  Medical  Device  “Plug-and-Play”  (MD  PnP) 
interoperability  standardization  framework  for  medical  devices  in  the  Operating  Room  of  the 
Future  (ORF)  and  across  the  continuum  of  healthcare.  To  effectively  define  these  requirements 
and  set  an  agenda  for  standards  development  required  convening  a  group  of  medical  device 
producers,  clinical  users,  biomedical  engineers,  governmental  regulators  (including  the  FDA), 
and  standards  experts.  The  two-day  symposium  was  organized  to  1)  educate  new  participants 
in  the  issues  and  barriers  to  implementing  MD  PnP  interoperability;  2)  provide  a  forum  to 
discuss  relevant  technology,  the  regulatory  picture,  and  the  refinement  of  clinical  requirements; 
3)  elicit  the  participants’  contributions  to  defining  the  vision  and  role  of  the  MD  PnP  Lab,  and  4) 
explore  the  benefits  of  broadening  the  initial  OR  of  the  Future-focused  “ORF  PnP”  initiative  to 
encompass  the  broader  healthcare  spectrum  as  “MD  PnP”. 


Body  of  Report 

The  second  MD  PnP  Symposium  jointly  sponsored  by  TATRC  and  Cl  MIT  was  held  on  June  6-7 
2005  at  Cl  MIT  in  Cambridge,  MA.  A  group  of  85  clinical  and  technical  thought  leaders  - 
medical  device  producers,  clinical  users,  biomedical  engineers,  governmental  regulators,  and 
standards  experts  -  participated,  including  40  clinical  and  academic  device  “users”  (9  from 
Kaiser  Permanente  and  6  from  New  York  Presbyterian),  40  industry  participants  from  21 
companies  (1 1  of  which  were  new  to  PnP),  2  from  engineering  societies  (IEEE  and  ACCE),  2 
FDA  staff,  and  a  TATRC  representative).  This  symposium  brought  together  these  diverse 
groups  for  the  third  time,  and  with  each  meeting  the  dialogue  has  moved  to  a  higher  level  of 
participation  and  mutual  understanding  of  program  goals  and  strategy.  Of  the  85  participants, 
46  were  new  to  the  program,  while  39  had  attended  a  previous  meeting  (in  May  or  November 
2004). 

As  in  the  previous  two  MD  PnP  plenary  meetings,  the  group  discussed  a  range  of  topics 
regarding  the  issues,  challenges,  and  potential  benefits  of  achieving  medical  device 
interoperability,  and  expanded  that  discussion  to  encompass  other  healthcare  environments 
such  as  home  health  care  and  ambulatory  practice.  The  agenda  (Appendix  A)  included 
speakers  from  related  academic  and  laboratory  programs;  an  update  on  the  work  with  the  FDA 
on  a  new  regulatory  paradigm;  breakout  sessions  to  discuss  high  level  clinical  requirements  and 
to  articulate  an  initial  plan  for  the  MD  PnP  Lab;  a  demonstration  of  the  potential  of  plug-and-play 
technology  for  medical  devices,  based  on  the  LiveData,  Inc,  “RTI”  integrated  display  system; 
two  other  lab  technology  demonstrations;  and  a  discussion  of  potential  system  architecture 
solutions.  With  the  focus  on  clinical  requirements  and  planning  the  lab,  this  meeting  moved  the 
program  from  the  conceptualizing  phase  to  the  planning  and  working  phase. 

Meeting  highlights  included: 

•  Broadening  of  the  stakeholder  community,  while  preserving  existing  interest 
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•  Multiple  attendees  from  new  companies  (including  Cisco,  Lockheed  Martin,  Olympus, 
Stryker,  Smith  &  Nephew,  and  others)  as  well  as  from  those  already  involved  (including 
Draeger,  GE  Healthcare,  Philips,  LiveData,  Datascope,  IBM,  and  others) 

•  Consolidation  and  categorization  of  the  high-level  clinical  requirements  collected  to  date 

•  Articulation  of  issues  and  considerations  for  planning  an  MD  PnP  “sandbox”  laboratory 
to  evaluate  proposed  interoperability  solutions  and  implement  clinical  use  cases 

•  Preliminary  definition  of  the  value  proposition  for  medical  device  interoperability 

•  Initial  discussion  of  a  framework  for  future  organization  and  funding  of  the  program 

•  Identification  of  paths  for  seeking  and  evaluating  potential  system  architecture  solutions 

•  Strong  consensus  for  the  PI  to  move  the  program  forward  to  the  next  phase 

Talks  given  at  the  symposium  were  videotaped  and  subsequently  made  available  as  streaming 
video  on  the  MD  PnP  (www.mdpnp.org)  and  Cl  MIT  web  sites  (www.cimit.org).  There  have 
been  almost  600  hits  on  these  pages  since  they  became  available  in  February.  Newcomers  to 
the  PnP  program  are  referred  to  these  talks,  as  well  as  those  from  the  May  2004  TATRC- 
sponsored  kick-off  symposium,  as  valuable  background. 

As  with  the  kick-off  symposium  in  May  2004,  this  symposium  led  to  a  series  of  related  follow-up 
activities  that  have  continued  to  broaden  support  for  the  MD  PnP  vision  and  goals.  These  have 
included  ongoing  work  on  refining  clinical  requirements  into  use  cases,  progress  towards  getting 
a  PnP  lab  up  and  running,  efforts  to  educate  additional  organizations  in  the  value  of  medical 
device  PnP,  visits  to  other  DoD-supported  programs  working  on  related  efforts,  and  meetings 
with  the  Office  of  the  National  Coordinator  for  Health  IT. 

The  high  level  clinical  requirements  that  we  collected  at  a  series  of  focus  group  sessions  held  at 
medical  societies  in  FY05  were  summarized  with  the  help  of  a  clinical  engineer  from  Kaiser 
Permanente  and  presented  at  the  June  symposium  in  a  breakout  group,  where  they  were 
further  discussed  and  refined.  In  August,  IBM  hosted  a  two-day  small  group  working  meeting  to 
organize  clinical  scenarios  in  an  FDA-recommended  framework.  Participants  in  this  meeting 
included  Kaiser  Permanente  and  the  FDA,  three  IBM  engineers  and  program  managers,  and 
the  MD  PnP  PI  and  Project  Manager.  The  session  resulted  in  a  set  of  clinical  requirements  that 
will  help  to  inform  engineering  specifications.  These  results  are  being  further  reviewed,  vetted 
with  clinical  groups,  and  extended  to  include  additional  requirements. 

Subsequent  to  the  June  symposium,  we  developed  a  more  complete  articulation  of  the  plan  for 
the  MD  PnP  Lab  and  the  various  roles  it  will  play  in  advancing  the  goal  of  achieving  MD  PnP 
interoperability.  A  significant  number  of  companies  (Draeger  Medical,  LiveData,  IBM,  Philips, 
GE,  and  Datascope)  and  Partners  Healthcare  Information  Systems  have  agreed  to  contribute 
equipment  and  engineering  help,  but  additional  funding  will  be  needed  to  hire  engineers  to  staff 
the  Lab. 

The  web  of  collaborations  for  the  MD  PnP  program  began  with  the  TATRC-sponsored  May 
2004  symposium  and  has  continued  to  grow  as  a  result  of  the  June  2005  MD  PnP  symposium. 
These  collaborations  include  activities  and  relationships  with  Federal  agencies;  clinical, 
engineering,  and  IT  societies;  clinicians  in  the  USA,  Europe,  and  Japan;  and  integrated  health 
delivery  networks. 

Collaboration  Highlights: 

•  The  Society  for  Technology  in  Anesthesia  (STA)  stated  their  ongoing  official  support  of 
the  work  and  created  an  MD  PnP  working  group  that  met  with  us  for  three  hours  at  the 
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STA  annual  meeting  in  January  2006  to  review  the  clinical  use  case  scenarios  compiled 
during  the  past  year  and  to  add  additional  requirements  where  needed. 

•  The  US  FDA/CDRH  has  committed  a  resource  to  provide  guidance  on  strategic  planning 
for  the  program,  methodology  for  interpreting  user  requirements,  and  guidance  for 
implementing  the  MD  PnP  Lab. 

•  On  the  recommendation  of  Gen.  Eric  Schoomaker  of  TATRC,  the  PI  met  with  Dr.  Fred 
Pearce  at  Walter  Reed  Medical  Center  to  discuss  potential  synergies  between  the  MD 
PnP  work  and  the  LSTAT  program.  This  was  synergistic  with  a  meeting  with  Dr.  Jose 
Salinas  at  the  U.S.  Army  Institute  of  Surgical  Research  at  Brooke  Army  Medical  Center. 
These  discussions  included  the  possibility  of  a  CRADA  to  facilitate  future  collaboration. 

•  Connections  made  at  HI  MSS  with  Dr.  David  Brailer  and  Dr.  John  Loonsk  of  the  National 
Health  IT  Coordinator’s  Office  led  to  subsequent  meetings,  enabling  the  PI  to  initiate  a 
dialogue  about  the  role  of  the  MD  PnP  program  in  supporting  the  national  health  IT 
agenda. 

•  The  National  Institute  of  Standards  and  Technology  invited  the  PI  to  participate  in  a 
workshop  on  “Open  ICT  Ecosystems  for  Healthcare,”  leading  to  several  important  new 
contacts. 

•  The  National  Science  Foundation  funded  a  plus-up  to  one  of  their  grantees  (University  of 
Pennsylvania)  working  on  modeling  the  safety  of  embedded  software  in  medical  devices, 
to  collaborate  with  the  MD  PnP  program. 

•  Kaiser  Permanente  is  including  language  in  its  new  contracts  requiring  medical  device 
interoperability  and  referring  to  our  MD  PnP  program,  and  is  also  assisting  with  the 
analysis  of  clinical  use  cases  and  providing  strategic  planning  guidance. 

•  Connections  made  with  IEEE  and  the  American  College  of  Clinical  Engineering  (ACCE) 
at  the  February  2005  HI  MSS  meeting  resulted  in  attendance  by  both  of  these  groups  at 
the  June  symposium,  and  the  PI  was  invited  to  attend  the  kick-off  meeting  in  September 
of  the  Patient  Care  Medical  Device  domain  group  initiated  by  representatives  of  IEEE 
and  ACCE  under  the  auspices  of  IHE.  Outcomes  of  this  collaboration  include  interest  on 
the  part  of  this  group  in  utilizing  the  MD  PnP  Lab  as  the  site  for  ongoing  testing  of 
medical  devices  against  standards,  and  provision  of  clinical  use  cases  from  the  MD  PnP 
program  to  the  IHE. 

These  collaborations  and  many  others  have  fed  an  ever-expanding  support  network  for  MD 
PnP,  increasing  the  likelihood  of  program  success. 

The  MD  PnP  web  site  (www.mdpnp.org,  formerly  www.orfpnp.org)  continues  to  serve  as  a 
vehicle  for  communication  and  discussion  forums  for  the  program.  The  email  distribution  list  for 
program  communication  expands  as  a  result  of  each  plenary  meeting  and  word-of-mouth,  and 
has  grown  to  more  than  415  names. 


Key  Research  Accomplishments 

•  Increased  the  momentum  of  the  MD  PnP  program  by  further  increasing  the  diverse, 
committed  stakeholder  community 

•  Made  excellent  progress  in  refining  the  high-level  clinical  requirements  elicited  from 
anesthesiologists,  surgeons,  and  clinical  engineers 

•  Maintained  a  close  working  relationship  with  FDA  that  involves  frequent  interaction  and 
committed  participation  in  this  effort 

•  Expanded  collaborations  with  NSF,  NIST,  and  University  of  Pennsylvania  to  include 
Draper  Lab,  Intel,  and  others,  to  enhance  the  quality  and  effectiveness  of  MD  PnP 
subprojects,  especially  use  case  implementation  in  the  Lab. 

•  Developed  a  clear  vision  and  scope  for  the  concept  of  a  vendor-neutral  laboratory,  and 
progressed  towards  implementation  of  a  prototype  MD  PnP  Lab  in  calendar  Q2  2006. 
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•  Initiated  high-level  dialogue  regarding  the  relationship  of  medical  device  interoperability 
to  the  national  health  IT  agenda. 

Reportable  Outcomes 

Meetings: 

•  August  2005  Clinical  Requirements  working  group  at  IBM  (7  participants) 

•  January  2006  MD  PnP  working  group  at  STA  (45  attendees) 

MD  PnP  Presentations: 

•  June  2005  at  Human  Factors  conference  sponsored  by  Association  for  the 
Advancement  of  Medical  Instrumentation  (AAMI) 

•  July  2005  at  Vanderbilt  Medical  Center 

•  July  2005  at  CIMIT  ORF  course 

•  October  2005  at  CIMIT  Annual  Briefing 

•  November  2005  at  AdvaMed  Software  Conference,  Washington  DC 

•  January  2006  at  STA  annual  meeting,  MD  PnP  working  group 

•  January  2006  “R.W.  Virtue  Lectureship”  at  University  of  Colorado 

•  February  2006  at  “Real-Time  GENI”  workshop  (NSF) 

•  February  2006  at  HIMSS  to  ACCE 

•  February  2006  at  HIMSS  to  LiveData  workshop 

•  February  2006  at  CIMIT  ORF  course 

•  February  2006  at  University  of  Arizona  Grand  Rounds,  Tucson 

•  March  2006  at  MIT  “M  Language”  workshop 

•  March  2006  at  NIST  “Open  ICT  Ecosystems”  workshop 

•  March  2006  at  University  of  Washington  Grand  Rounds,  Seattle 

•  March  2006  at  International  Anesthesia  Research  Society  annual  meeting 

Web  Sites: 

•  www.mdpnp.org  (formerly  www.orfpnp.org)  maintained  as  major  communication  vehicle 

•  Online  interactive  project  planning  site  for  working  group  on  x-ray  /  ventilator  lab 
demonstration  project 

Manuscripts/Publications: 

•  24x7mag.com:  Section  on  “The  Interoperability  Payoff,  based  on  Interview  with  Julian 
Goldman,  in  article  on  RFID,  October  2005 

•  Mass  High  Tech:  Interview  with  Julian  Goldman  re  MD  PnP  Program,  November  2005. 

•  Goldman  JM,  Jackson  JL,  Whitehead  SF,  Rausch  TL,  Weininger  S,  “The  Medical  Device 
‘Plug-and-Play’  (MD  PnP)  Interoperability  Program,”  part  of  Schrenker  RA,  “Software 
Engineering  for  Future  Healthcare  and  Clinical  Systems,”  IEEE  Computer,  April  2006. 

•  Goldman  JM,  “Medical  Device  Connectivity  for  Improving  Safety  and  Efficiency,” 
American  Society  of  Anesthesiology  Newsletter  70:5,  May  2006. 
http://www.asahq.org/Newsletters/2006/05-06/goldman05_06.html 

Funding  Applications: 

•  Funded:  CIMIT:  $77K  for  FY06  core  support  of  the  Principal  Investigator  (12%)  and 
Project  Manager  (25%) 

•  Funded:  DoD:  SBIR  Phase  II  extension  for  LiveData  grant,  to  support  application  of  their 
work  to  PnP  Lab 

•  Award  expected  in  May  2006:  TATRC  BAA,  $249K  for  1  year  for  core  program  support 
for  the  PI  (35%)  and  Project  Manager  (25%) 
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•  Submitted:  Partners  Healthcare  IS  Research  Council:  $74. 5K  for  Developing  Formal 
Requirements-Engineering  Methodology  in  Support  of  the  MD  PnP  Program 

•  Submitted:  Cl  MIT:  $76K  for  FY07  for  core  support  of  the  Principal  Investigator  (12%) 
and  Project  Manager  (25%);  jointly  with  Draper  Lab,  $75K  for  FY07  for  clinical  scenario 
modeling  and  systems  engineering  for  the  PnP  Lab  architecture 


Other: 


•  In-kind  engineering  support  and  contribution  of  equipment  for  the  lab  from  Draeger 
Medical,  FDA,  Draper  Laboratory,  Kaiser  Permanente,  and  LiveData,  and  commitments 
from  several  other  companies. 


Conclusions 

This  second  MD  PnP  symposium  supported  by  TATRC  and  Cl  MIT  built  on  the  work  from  the 
previous  year  to  leverage  effective  advancement  of  the  MD  PnP  program  towards  developing  a 
standardization  framework  for  medical  device  interoperability.  Significant  progress  was  made  in 
the  areas  of  clinical  requirements  for  MD  PnP  and  development  of  a  vision  and  plan  for  an  MD 
PnP  “sandbox”  laboratory.  The  network  of  collaborators  and  stakeholders  continues  to  expand, 
further  confirming  the  relevance  of  the  work,  and  concrete  activities  related  to  clinical  scenarios 
and  the  MD  PnP  Lab  have  begun. 
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of  “The  Search  Is  Over”  (article  on  RFID),  24x7mag.com,  October  2005. 

5.  Hendrickson  D,  “Rx  for  the  OR:  Mass.  Physicians  tap  experience  and  tech  leaders  to 
bring  better  medical  solutions  to  market”  (interview  with  Julian  Goldman  re  MD  PnP 
Program),  Mass  High  Tech,  November  2005. 

6.  Goldman  JM,  Jackson  JL,  Whitehead  SF,  Rausch  TL,  Weininger  S,  “The  Medical  Device 
‘Plug-and-Play’  (MD  PnP)  Interoperability  Program,”  part  of  Schrenker  RA,  “Software 
Engineering  for  Future  Healthcare  and  Clinical  Systems,”  IEEE  Computer,  April  2006. 

7.  Goldman  JM,  “Medical  Device  Connectivity  for  Improving  Safety  and  Efficiency,” 
American  Society  of  Anesthesiology  Newsletter  70:5,  May  2006. 
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Third  Meeting  of  the  ORF  PnP  Standardization  Program 

A  multidisciplinary  program  to  develop  standards  for  communication 
and  control  of  medical  devices  in  the  OR  of  the  Future 
to  improve  patient  safety  and  healthcare  efficiency 


Sponsored  by:  CIMIT  &  TATRC 
Hotel@MIT,  20  Sidney  Street,  Cambridge,  MA 

Monday,  June  6 

8:00  -  9:00am  Registration  /  Continental  Breakfast 


9:00  -  9:15am 


9:  15-10:00 


10:00-10:15 


10:15-10:35 


10:35-10:45 


Welcome  from  CIMIT  and  TATRC 
John  A.  Parrish,  MD 

Director,  Center  for  the  Integration  of  Medicine  &  Innovative 
Technology  (CIMIT) 

Ronald  Marchessault,  MBA 

U.S.  Army  Telemedicine  &  Advanced  Technology  Research 
Center  (TATRC) 

Conference  Overview 

Year  1  Activities  of  ORF  PnP  Standardization  Program 
Julian  M.  Goldman,  MD 
Principal  Investigator,  ORF  PnP  Program 
CIMIT/Massachusetts  General  Hospital 

The  HCMDSS  Connection  (High  Confidence  Medical  Device 
Software  &  Systems)  -  Report  from  the  June  2-3  Workshop 
Insup  Lee,  PhD 

Director,  Systems  Design  Research  Lab 
Department  of  Computer  and  Information  Science 
School  of  Engineering  &  Applied  Science 
University  of  Pennsylvania 

0R2020:  Final  Report  from  the  March  2004  Workshop 
Kevin  Cleary,  PhD 

Deputy  Director,  Imaging  Science  &  Information  Systems  Center 
Department  of  Radiology 
Georgetown  University  Medical  Center 

Break 
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Monday,  June  6  (continued) 

10:45am  -  12:15pm  WG1:  Clinical  Requirements  for  PnP  in  the  ORF 

Results  of  Clinical  Requirements  Focus  Groups: 


Society  for  Technology  in  Anesthesia  (STA)  -  January  13 

Julian  M.  Goldman,  MD 

Society  of  American  Gastrointestinal  Endoscopic  Surgeons 
(SAGES)  -  April  15 

Marc  Shapiro,  Olympus  America  Inc. 

Additional  Medical  Forums 

Julian  M.  Goldman,  MD 

Examples  of  Clinical  Use  Cases  Beyond  the  OR 

Kaiser  Permanente 

Association  for  the  Advancement  of  Medical  Instrumentation 
(AAMI)  -  May  14 

Jennifer  Jackson,  MBA,  Biomedical  Engineering 

Brigham  &  Women’s  Hospital 

Extracting  Engineering  Requirements  from  Clinical  Use  Cases 

Jim  DelloStritto 

Protocol/Welch-Allyn 

12:15-  1:15pm 

Networking  Lunch  Buffet  (find  someone  interesting  to  sit  with!) 

1:15 -2:00pm 

Vision  for  a  PnP  Laboratory 

Julian  M.  Goldman,  MD 

Sandy  Weininger,  FDA 

Jeff  Robbins,  LiveData  Inc. 

Experience  at  the  University  of  New  Hampshire  Interoperability  Lab 
Gerard  (Gerry)  Nadeau,  Manager,  UNH-IOL 

2:00-2:10 

Instructions  for  breakout  sessions 

Julian  M.  Goldman,  MD 

2:10-2:15 

Move  into  groups 

2:15-4:00 

Breakout  Session  1:  Clinical  Requirements  ->  Engineering 
Requirements 

Review,  refine,  add  new  clinical  input,  develop  implementation 
plan  to  hand  off  to  WG3 

Facilitators:  Julian  M.  Goldman,  and  Sandy  Weininger,  FDA 

Scribe:  Bridget  Moorman,  Kaiser  Permanente 
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Monday,  June  6  (continued) 


2:15  -4:00pm 

Breakout  Session  2:  Shaping  the  Vision  of  the  PnP  Lab 
Facilitator:  Jeff  Robbins,  LiveData  Inc. 

Scribe:  Rick  Schrenker,  Biomedical  Engineering 

Massachusetts  General  Hospital 

4:00-5:30 

Groups  Report  Back 

Identify  Next  Steps 

Facilitator:  Bill  Joiner 

5:30  and  6:30pm 

Reception  and  Dinner 

Dinner  Speaker:  Warren  M.  Zapol,  MD 

Reginald  Jenny  Professor  and  Chairman,  Department  of 
Anesthesia  and  Critical  Care,  Massachusetts  General  Hospital 

Tuesday,  June  7 

7:00  -  8:00am  Continental  Breakfast 


8:00  -  8:10am 

Introduction  to  Day  #2 

8:10-8:40 

WG2:  Regulatory 

Jennifer  A.  Henderson,  JD,  MPH,  CIMIT 

8:40-9:10 

Investigating  the  PnP  Value  Proposition 

Davis  Bu,  MD,  C!TL,  and  Michael  Robkin,  Kaiser  Permanente 

9:10-9:30 

IHE  Point-of-Care  Medical  Device  Initiative 

Ray  Zambuto 

Past  President,  American  College  of  Clinical  Engineering 

IEEE  1073  General  Committee 

9:30  -  9:45 

Break 

9:45-11:00 

Introduction  to  PnP  Lab  Demos 

Julian  M.  Goldman,  MD 

Jeff  Robbins,  LiveData  Inc. 

Jim  DelloStritto,  Protocol/Welch-Allyn 

Sebastien  Cadet,  World  of  Medicine 

Others  TBA 

11:00am  -  1:30pm 

PnP  Lab  Demos  &  Lunch 

Attendees  will  form  3-4  smaller  groups  to  network  and  view  demos 
at  hotel  and  at  CIMIT  Simulation  Center  (2  blocks  away)  -  buffet 
lunch  will  be  provided  and  available  at  hotel  during  this  period. 
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Tuesday,  June  7  (continued) 


1:30  -  3:00pm 


3:00-3:15 

3:15-5:00 


5:00pm 


Discussion  of  Proposed  PnP  Lab  Projects 
Julian  M.  Goldman,  MD 

Model  for  Engaging  Industry 
Abe  Abramovich 
Director,  Advanced  Technology 
Datascope  Corporation 

Long-Term  Funding  Strategy  for  the  ORF  PnP  Program  -  What 
Should  the  Model  Be? 

Jennifer  Jackson,  MBA,  and  Julian  M.  Goldman,  MD 
Next  Steps 

Julian  M.  Goldman,  MD 
Break 

WG3:  Communication  Architecture 

Chaired  by  Bill  Seitz,  IXXAT  Inc.,  and  Jeff  Robbins,  LiveData  Inc. 
Scribe:  Jennifer  Jackson 
Facilitator:  Bill  Joiner 

Group  input  on  development  of  architectural  roadmap 

Adjourn 
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June  Attendees  Roster 


June  2005  PnP  Standards:  Attendees 

By  Institution/Company 

Institution/  Company 

Name 

Email 

American  College  of  Clinical  Engineering 

Zambuto,  Ray 

rzambuto(S)techmed.com 

ACIST  Medical  Systems,  Inc. 

Lafayette,  Gregg 
Maiers,  Manfred 

qreqq.lafavette(S)acistmedical.com 

manfred.maiers(a>acistmedical.com 

Brigham  &  Women's  Hospital 

Daniel,  Ernst 

Feldman,  Charles 
Jackson,  Jennifer 

edaniel(5).partners.orq 

CLFeldmanflJearthlink.net 

iliackson(a>partners.orq 

CAN  in  Automation 

Menon,  Cyrilla 

menon(S)can-cia.orq 

ChangeWise,  Inc. 

Joiner,  Bill 

bi(a)chanqewise.biz 

CIMIT 

Brown,  Beverly 

Crosby,  Janice 
Henderson,  Jennifer 
Humphrey,  Ann 

Parrish,  John 
Whitehead,  Susan 

bbrown9(a)partners.orq 

iecrosbv(5).partners.orq 

iahenderson(a>partners.orq 

ahumphrev(a)partners.orq 

iaparrishfltoartners.orq 

swhitehead(a)partners.orq 

Cisco  Systems,  Inc. 

Lohmann,  Andrew 

lohmann(a)cisco.com 

Datascope  Corporation 

Abramovich,  Abe 

Eaton,  Scott 

Fidacaro,  Jim 

Parsons,  Samuel 

abe  abramovichfiSdatascope.com 

scott  eaton(Q)datasco pe.com 

iim  fidacaro(S)datascope.com 

sparsons(a)datascope.com 

Draeger  Medical  Systems,  Inc. 

Clark,  Robert 

Fuchs,  Ken 

Wallroth,  Carl 

clarkrflJdraeqermed.com 

ken.fuchs(a)draeqer.com 

Beate.Moeller(a>draeqer.com 

Duke  University  Medical  Center 

Weitzner,  Stanley 

weitzOOl  (a)mc.  duke.edu 

EQ  International 

Juett,  Steve 

siuettflJeointl.com 

FDA 

Husband,  Michael 
Weininger,  Sandy 

MJH(®CDRH.  FDA.GOV 

sxw(a)cdrh.fda.qov 

GE  Healthcare  Technologies 

Schluter,  Paul 

Seidl,  Neal 

Paul.  Schluter®.  med.qe.  com 

neal.seidl(a)med.  qe.com 

Georgetown  University  Medical  Center 

Cleary,  Kevin 

clearv(S)qeoroetown.edu 

Harvard  University 

Hedley-Whyte,  John 
Milamed,  Debra 

iohn  hedlev-whvte@.hms. harvard.edu 

debra  milamed(a)hms. harvard.edu 

IBM 

IBM  TJ  Watson  Research  Center 

Perrera,  Chris 

Williams,  Rose 

perrera(S)us.  ibm.com 

rosemw(a)us. ibm.com 

IEEE 

Cooper,  Todd 

t.cooper(S)ieee.oro 

iMDsoft 

Shefi,  Moshe 

moshe. shefi(a)imd-soft. com 

IXXAT  Automation  GmbH. 

IXXAT,  Inc. 

Schlegel,  Christian 
Seitz,  Bill 

schleqel(a)ixxat.de 

seitz(3)ixxat.com 
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June  Attendees  Roster 

Kaiser  Permanente 

Howse,  John 

Judd,  Thomas 

Moorman,  Bridget 

Morris,  Robert 

Rausch,  Tracy 

Robertson,  Scott 

Robkin,  Michael 

Snyder,  Bob 

Wang,  Jing 

JHowse65400aol.com 

tom.iuddOkp.orq 

bridqet.moormanOkp.orq 

robert.i. morris®  ko.orq 

tracv.rauschOkp.orq 
scott. m.robertsonOkp. orq 

Michael. B.RobkinOkp.orq 

BobSnvder400®aol.com 

iinq.m.wanqOkp.orq 

LiveData,  Inc. 

Brzezinski,  Philip 

Cohen,  Brett 

Cullinane,  John 

Hughes,  Kevin 

Robbins,  Jeffrey 

pbrzezinski®earthlink.net 

bcohenOlivedata.com 

iohn®cullinane-qroup.com 

kevinhOlivedata.com 

ieffr®livedata.com 

Lockheed  Martin 

Barton,  Douglas 

douqlas.e. bartonOlmco.com 

Massachusetts  General  Hospital 

Berman,  Jesse 

Goldman,  Julian 
Sandberg,  Warren 
Schrenker,  Rick 

iberman®  partners,  orq 
imooldmanOoartners.orq 

wsandberq®  partners. orq 

raschrenkerOoartners.orq 

Medtronic  Emergency  Response  System 

Peterson,  Ken 

ken. peterson®  medtronic.com 

MIT  -  AutolD  Lab 

Mun,  In 

ikmlOMIT.EDU 

New  York  Presbyterian  Hospital 

Deland,  Emme 

Fowler,  Dennis 

Milsom,  Jeffrey 

Mirsky,  Michael 

Riina,  Howard 

Suberman,  Abbie 

eld9009(5).nvp.orq 

dlf20010nvo.orq 
iwm2001  ®med.  cornell.edu 

mim9026Onvp.orq 
har9005®med.  cornell.edu 

abs90080nvo.orq 

Olympus  America,  Inc. 

Masuda,  Hiroshi 

Mino,  Hiroyuki 

Shapiro,  Marc 

laureen.bufaloOolvmpus.com 

hirovuki.mino®olvmpus.com 

marc. shapiro®olvmpus. com 

Partners  Healthcare 

Bu,  Davis 

Vasios,  George 

dbuOpartners.orq 

qeorqevasiosOcomcast.net 

Philips  Medical  Systems,  Inc. 

Harrington,  Jack 

Weisner,  Steve 

Wittenber,  Jan 

iack.harrinqton®philips.com 

steve.weisner®  philips. com 

ian.wittenberOphilips.com 

Sg2 

Maji,  Catherine 
Venkatraman,  Giri 

clmaii®sq2.com 

qiri  venkatraman®vahoo.com 

Smith  &  Nephew  Endoscopy 

Reed,  Howard 

Howard.  Reed®Smith-Nephew. com 

Stryker 

Malackowski,  Don 
Wildgen,  Mike 

don .  malackowskiOstrvker.com 

mike.wildqen®strvker.com 

Tyco  Healthcare,  Inc. 

Zanetti,  Richard 

Richard.ZanettiOtvcohealthcare.com 

University  of  New  Hampshire 
Interoperability  Lab 

Nadeau,  Gerard  (Gerry) 

qrn®  iol.  unh.edu 

University  of  Pennsylvania 

Lee,  Insup 

leeOcentral.cis.upenn.edu 
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U.S.  Army  Telemedicine  &  Advanced 
Technology  Research  Center 

Vanderbilt  University  Medical  Center 

Welch  Allyn  Inc. 

World  of  Medicine  USA,  Inc. 


Marchessault,  Ron 

Patel,  Nimesh 
St.  Jacques,  Paul 

DelloStritto,  Jim 

Cadet,  Sebastien 


marchessault@TATRC.ORG 

nimesh.patel@vanderbilt.edu 

paul.stiacaues@vanderbilt.edu 

DelloStrittoJ@welchallvn.com 

sebastien.cadet@womcorp.com 
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Medical  Device  Plug-and-Play  (MD  PnP)  Interoperability  Program 

at  Massachusetts  General  Hospital  and  Cl  MIT 

MD  PnP  Laboratory  Vision  &  Scope 


High-acuity  healthcare  remains  complex  and  potentially  dangerous,  in  part  because  clinicians  depend  on 
teamwork  and  a  patchwork  of  systems  to  mitigate  hazards  instead  of  using  integrated  “error  resistant”  safety 
systems  and  automated  decision  support.  As  a  result  of  the  lack  of  medical  device  interoperability,  many 
self-evident  improvements  in  data  communication  (e.g.  shared  and  centralized  information),  device 
integration,  and  human  factors  have  not  been  achieved,  and  patient  safety  and  economic  benefits  not 
realized.  Without  medical  device  interoperability,  goals  of  remote  device  control  and  closed-loop  control 
systems  cannot  be  attained.  The  Medical  Device  Plug-and-Play  program  was  initiated  to  remove  the  barriers 
to  implementing  comprehensive  clinical  interoperability  solutions  that  will  facilitate  the  widespread  clinical  use 
of  medical  device  data  and  network-based  medical  device  control.  These  barriers  include  the  absence  of 
validated  interoperability  standards  and  specific  clinical  requirements,  and  legal  and  regulatory  concerns. 

We  are  creating  a  vendor-neutral  MD  PnP  Lab  “sandbox”  populated  with  medical  devices  that  will  serve  as 
the  focal  point  of  the  MD  PnP  program.  The  MD  PnP  Lab  will  be  used  to  demonstrate  and  assess  clinical 
examples  of  interoperability-based  safety  solutions,  beginning  with  intra-operative  care.  Our  experience 
implementing  the  Operating  Room  of  the  Future  at  Massachusetts  General  Hospital  (MGH)  will  inform  this 
process.  During  the  past  year,  we  elicited  clinical  scenarios  from  over  200  clinicians  and  clinical  engineers  at 
multiple  meetings  throughout  the  United  States  to  identify  examples  in  which  the  deployment  of  medical 
device  interoperability  standards  could  improve  patient  safety  and  healthcare  efficiency  in  the  perioperative 
environment.  Selected  “high-level  clinical  use-cases”  will  be  implemented  in  the  MD  PnP  Lab  in  order  to 
study  their  potential  clinical  utility  and  to  inform  the  selection,  development,  and  implementation  of  candidate 
interoperability  standards.  Once  vetted,  candidate  standards  will  be  incorporated  into  an  “MD  PnP 
standardization  framework”  that  will  serve  as  an  umbrella  standard  for  medical  device  interoperability. 

We  will  continue  to  draw  on  clinical  resources  to  assure  that  clinical  requirements  remain  the  foundation  of 
the  derived  technical  specifications,  and  plan  to  coordinate  the  work  with  the  Integrating  the  Healthcare 
Enterprise  (IHE)  program  of  the  Health  Information  and  Management  Systems  Society  (HIMSS)  to  support 
cross-domain  interoperability. 

The  MD  PnP  Lab  must  meet  the  challenge  of  networking  currently  available  medical  devices  that  do  not  use 
standardized  network  and  communication  interfaces,  in  order  to  create  an  appropriate  development 
environment  to  (1)  evaluate  clinical  scenarios,  (2)  investigate  the  performance  of  candidate  medical  device 
interoperability  standards,  (3)  develop  reference  implementations  of  selected  standards  that  are  optimized 
for  medical  device  PnP  environments,  and  (4)  document  the  benefits  and  limitations  with  respect  to  clinical 
and  technical  requirements.  Fortunately,  a  vendor  that  has  successfully  deployed  a  system  with  the 
capability  of  networking  disparate  non-standardized  devices  in  the  OR  of  the  Future  has  volunteered 
resources  to  deploy  that  system  in  the  MD  PnP  Lab.  This  example  of  a  non-standardized  networked 
environment  will  provide  a  platform  for  rapid  prototyping  of  standards-based  solutions.  Other  vendors  and 
governmental  agencies  have  committed  to  support  the  Lab  with  donations  of  medical  devices  and 
engineering  support. 

The  national  impetus  to  improve  Healthcare  IT  has  been  accelerated  through  bi-partisan  support  from  the 
Executive  and  Legislative  branches  of  government.  The  broad  appeal  of  the  MD  PnP  program  is  due  in  part 
to  the  alignment  of  its  goals  with  pent-up  national  healthcare  demands  for  interoperability.  The  MD  PnP  Lab 
will  support  the  national  health  IT  initiative  by  leveraging  the  consensus  model  of  the  MD  PnP  Program  (with 
diverse  clinical,  vendor,  and  governmental  involvement  -  including  the  FDA  and  DoD)  to  encourage  broad 
stakeholder  involvement  and  lead  the  adoption  of  interoperability  solutions.  We  expect  the  MD  PnP  Lab  to 
evolve  into  a  national  resource  for  Medical  Device  Interoperability  and  Patient  Safety  for  the  design, 
evaluation,  and  implementation  of  interoperable  systems. 

Julian  M.  Goldman,  MD  Sue  Whitehead 

MD  PnP  Program  Director  Operations  Manager  /  MD  PnP  Project  Manager 

Massachusetts  General  Hospital,  Boston,  MA  Center  for  the  Integration  of  Medicine  &  Innovative 
imqoldman@.partners.orq  Technology  (CIMIT) 

Mobile  617-827-2950  65  Landsdowne  Street,  Suite  200,  Cambridge,  MA  02139 

www.mdpnp.org  Office  617-768-8760,  Fax  617-768-8770 

swhitehead@partners.org 

Revised  January  5,  2006  (c)  2006  Julian  M.  Goldman,  MD 
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GUEST  EDITOR’S  I N  T  R  0  D  U  C  T I  0 


Clinical 

SSMware 


Software 
Engineering 
for  Future 
Healthcare 
and  Clinical 
Systems 

Richard  A.  Schrenker 

Massachusetts  General  Hospital 


Systems  and  software  engineering  contribute  not  only  to  advancing  and  improving  the 
delivery  of  healthcare  but  also  to  doing  it  more  safely  than  has  been  the  case  in  the  past. 


Turning  “To  err  is  human,  but  to  really  screw  up, 
you  need  a  computer”  on  its  head,  in  1999  the 
Institute  of  Medicine’s  To  Err  Is  Human:  Build¬ 
ing  a  Safer  Health  Care  System  recommended1 
that  healthcare  professionals  focusing  on  patient 
safety  should  increase  their  understanding  of  how  infor¬ 
mation  technology  could  be  applied  to  deliver  safer  care. 
This  recommendation  was  made  as  part  of  the  approach 
to  reducing  errors  in  the  delivery  of  care  leading  to  the 
death  of  as  many  as  98,000  US  citizens  annually. 

Much  of  the  subsequent  response  to  that  challenge 
has  focused  on  increasing  the  capabilities  of  enterprise 
hospital  and  clinical  information  systems — for  exam¬ 
ple,  implementing  order-entry  systems  to  check  for  drug 
allergies  when  writing  prescriptions.  But  IT  and  patient 
care  also  come  together  at  the  bedside  in  the  medical 
equipment  and  instrumentation  systems  used  to  deliver 
direct  patient  care — for  example,  smart  infusion  pumps 
that  help  ensure  that  the  right  dose  of  the  right  drug  is 
administered  to  the  right  patient. 

The  articles  in  this  special  issue  will  touch  on  both 
types  of  systems,  while  focusing  primarily  on  the  appli¬ 
cation  of  software  and  systems  engineering  to  software- 
based  medical  devices  and  device  systems  used  at  the 
bedside. 


REVISITING  THE  PAST 

There  is  no  free  lunch,  of  course.  That  software  brings 
risks  of  its  own  to  healthcare  technology  was  not  news 
in  1999.  Six  years  before  To  Err  Is  Human ,  Computer 
published  an  evaluation  of  the  Therac-25  accidents  in 
which  Nancy  Leveson  and  Clark  Turner  provided  what 
retrospectively  may  be  seen  as  a  “warning  shot”  regard¬ 
ing  the  impact  of  software  on  medical  technology.2 
Under  “Lessons  Learned,”  they  quoted  a  medical  physi¬ 
cist: 

We  have  assumed  ...  manufacturers  have  all  kinds  of 
safety  design  experience  since  they’ve  been  in  the  busi¬ 
ness  a  long  time.  We  know  that  there  are  many  safety 
codes,  guides,  and  regulations  to  guide  them  and  we 
have  been  reassured  by  the  hitherto  excellent  record  of 
these  machines  ...  Perhaps,  though,  we  have  been 
spoiled  by  this  success. 

The  authors  go  on  to  note: 

If  we  assign  software  error  as  the  cause  of  the  Therac- 
25  accidents,  we  are  forced  to  conclude  that  the  only 
way  to  prevent  such  accidents  in  the  future  is  to  build 
perfect  software  that  will  never  behave  in  an  unexpected 
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or  undesired  way  under  any  circumstances  (which  is 
clearly  impossible)  or  not  to  use  software  at  all  in  these 
types  of  systems. 

They  also  note  that  “Although  using  good  software  engi¬ 
neering  practices  will  not  prevent  all  software  errors,  it 
is  certainly  required  as  a  minimum”  and  that  “Safety  is 
a  quality  of  the  system  in  which  the  software  is  used;  it 
is  not  a  quality  of  the  software  itself.” 

These  warnings  echo  in  the  enter¬ 
prise  domain  as  well.  In  “Some 
Unintended  Consequences  of  Infor¬ 
mation  Technology  in  Health  Care: 

The  Nature  of  Patient  Care  Infor¬ 
mation  System-Related  Errors,” 

Joan  Ash  and  colleagues  cite  exam¬ 
ples  of  PCIS  failures  that  led  to 
decreased  safety,  the  opposite  intent 
of  its  design.3  They  recommend  that 
“developers  and  vendors  should  be 
clearer  about  the  limitations  of  their 
technologies.” 

That  said,  today’s  limitations  may  have  been  yester¬ 
day’s  advanced  features.  Given  the  increasing  rate  of 
change  of  technological  innovation  and  its  introduction 
into  healthcare  delivery,  it  is  not  surprising  to  find  dif¬ 
ferent  vintages  of  similar  systems  simultaneously  avail¬ 
able  in  clinical  practice.  This  in  turn  can  lead  to  originally 
unanticipated  user  expectations  being  applied  to  older 
systems,  potentially  resulting  in  unintended  consequences 
not  only  in  their  application  but  also  for  developers,  as 
described  in  the  “Healthcare  Professionals’  Perceptions 
of  Medical  Software  and  What  to  Do  About  It”  sidebar 
by  Phillip  A.  Laplante  and  coauthors. 

A  similar  problem  is  reflected  at  the  point  of  delivery 
of  care,  where  an  increasing  number  of  medical  devices 
are  embedded  systems  with  complexity  and  capabilities 
that  exceed  products  from  just  a  few  years  ago. 

Providing  care  to  any  one  patient  is  likely  to  require 
multiple  devices,  particularly  for  the  more  acutely  ill. 
The  instrumentation  at  an  intensive  care  bedside  will 
minimally  include  a  physiologic  monitoring  system  to 
acquire,  process,  communicate,  display,  and  generate 
appropriate  alarms  for  ECG,  one  or  more  blood  pres¬ 
sure  devices,  and  devices  for  monitoring  oxygen  satu¬ 
ration,  cardiac  output,  respiration,  and  other  key 
parameters.  Other  devices  likely  to  be  in  use  will  include 
infusion  pumps  (smart  or  otherwise)  and  a  ventilator. 
Equipment  that  can  be  brought  in  as  needed  includes 
dialysis  systems  and  laboratory  equipment  such  as  auto¬ 
mated  blood  and  chemistry  analyzers. 

Some  patients  will  need  all  of  the  above  and  perhaps 
more;  others  will  present  different  needs.  Assuring  the 
readiness  and  availability  of  this  equipment  requires 
having  a  robust  and  reliable  medical  technology  man¬ 
agement  system. 


CHALLENGES  AHEAD 

Responding  to  the  demands  of  the  patient  care  envi¬ 
ronment  requires  (among  other  things)  hospital  medical 
equipment  inventories  that  are  not  only  well-stocked — 
we  currently  manage  more  than  18,000  devices  for  our 
approximately  1,000-bed  hospital — but  fairly  dynamic 
as  well.  New  equipment — and  new  makes,  types,  and 
models  of  equipment — is  added  continuously,  often 
replacing  outdated  equipment,  but  sometimes  provid¬ 
ing  new  functionality.  Consequent 
human  factors  as  well  as  technical 
and  user  training  issues  require 
ongoing  monitoring  and  attention. 

None  of  this  is  terribly  new,  but  the 
addition  of  software-based  medical 
devices  adds  more  wrinkles.  Henry 
Petroski’s4  admonition  is  worth 
remembering: 

Any  design  change  . . .  can  introduce 
new  failure  modes  or  bring  into  play 
latent  failure  modes.  Thus  it  follows 
that  any  design  change,  no  matter  how  seemingly  benign 
or  beneficial,  must  be  analyzed  with  the  objectives  of 
the  original  design  in  mind. 

Managing  software  versions,  installing  patches,  or  plac¬ 
ing  devices  on  shared  network  infrastructures  are  exam¬ 
ples  of  activities  that  are  already  introducing  new  sets  of 
problems  to  the  clinical  environment,  including  some  that 
have  yet  to  manifest  themselves. 

Manufacturers,  regulators — for  example,  the  FDA — 
and  medical  equipment  users  all  have  played  roles  in  the 
evolution  of  medical  technology  management  systems 
that  have  brought  us  to  this  point.  Viewing  the  process 
from  30,000  feet,  manufacturers  develop  a  device;  reg¬ 
ulators  approve  it  for  sale;  and  users  buy,  use,  and  main¬ 
tain  it.  But  it  is  not  clear  whether  this  model  will  remain 
sustainable  going  forward,  as  clinical  demands  driving 
technological  responses  appear  to  point  to  the  need  for 
a  less  linear  and  more  collaborative  process  among  the 
involved  parties.  For  example,  currently  there  is  little  in 
the  way  of  standards-based  interoperability  among  med¬ 
ical  devices,  even  in  the  presence  of  ongoing  efforts  like 
IEEE  11073,  which  date  back  to  the  early  1990s. 

Why  these  efforts  have  yet  to  succeed  is  not  fully  clear 
even  to  those  of  us  who  have  been  involved.  However, 
over  the  past  few  years,  a  movement  has  started  to  take 
shape  that  is  characterized  not  only  by  increased  col¬ 
laboration,  but  also  by  users  taking  a  more  active  role 
in  establishing  the  vision  for  future  systems  and  deriv¬ 
ing  the  requirements  to  which  manufacturers  and  regu¬ 
lators  need  to  respond. 

Active  efforts  following  this  model  include  the  creation 
of  the  American  College  of  Clinical  Engineering-sponsored 
Domain  for  Patient  Care  Devices  within  the  Integrating 
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is  described  by  Julian  Goldman  and  coauthors  in  their 
“The  Medical  Device  ‘Plug-and-Play’  (MD  PnP)  Inter¬ 
operability  Program  ”  sidebar. 


the  Healthcare  Enterprise  Initiative  (IHE  PCD),5  in  which 
the  collaborators  include  clinicians,  engineers,  and  infor- 
maticists  from  healthcare  providers  as  well  as  federal  reg¬ 
ulatory  staff,  manufacturers,  and  standards  experts. 
Another  derives  from  work  started  in  the  Massachusetts 
General  Hospital’s  Operating  Room  of  the  Future6  and 


BROAD  VISION,  NATIONAL  AGENDA 

Much  like  the  fable  of  the  blind  men  describing  an 


Healthcare  Professionals'  Perceptions  of  Medical  Software 
and  What  to  Do  About  It 


Phillip  A.  Laplante,  Colin  J.  Neill,  and  Raghvinder  Sangwan 
Penn  State  University 

A  March  2005  article  by  Ross  Koppel  and  colleagues  in  the 
Journal  of  the  American  Medical  Association  exemplifies  a 
sequence  of  reports  highly  critical  of  various  kinds  of  medical 
informatics  systems.1  In  this  case,  a  computerized  physician 
order  entry  system  deployed  at  the  University  of  Pennsylvania 
Medical  Center  came  under  fire.The  article  concluded  that, 
contrary  to  conventional  belief,  a  CPOE  system  might  actually 
increase  the  number  of  medication  errors  as  compared  to  a 
manual,  handwritten  system. 

As  faculty  working  at  a  graduate  center  with  the  mission  of 
advancing  the  profession  of  software  engineering,  we  were 
aghast  at  the  implications  (accusations,  really)  of  the  study 
reported  in  this  article — that  the  software  engineering 
employed  in  the  development  of  this  system  was  deficient  or 
delinquent  and  was  therefore  an  indication  that  our  discipline 
is  itself  lacking.  Particularly  disconcerting  was  how  the  main¬ 
stream  media  picked  up  the  article  and  further  promoted 
the  notion  that  software  engineers  were  failing  the  medical 
profession. 

Physicians'  Perceptions  of 
Software  Engineering  Practices 

The  Eclipsys  CPOE  system  scrutinized  in  this  study  appar¬ 
ently  was  deployed  from  1 997  until  2004. When  we  contacted 
them,  Eclipsys  employees  confirmed  that  because  it  had 
screens  that  were  “usually  monochromatic  with  pre- 
Windows  interfaces,”  this  was  probably  an  older-generation 
system. 

In  any  case,  the  conclusions  drawn  in  the  JAMA  article 
about  CPOE  system  design  can  be  stated  as  follows: 

•  Focus  primarily  on  the  organization  of  the  work,  not  on 
technology. 

•  Aggressively  examine  the  technology  in  use. 

•  Aggressively  fix  technology  when  it  is  shown  to  be  coun¬ 
terproductive. 

•  Pursue  errors’  “second  stories”  and  multiple  causations 
to  surmount  barriers  enhanced  by  episodic  and  incomplete 
error  reporting. 

•  Plan  for  continuous  revisions  and  quality  improvement,  rec¬ 
ognizing  that  all  changes  generate  new  error  risks. 


These  are  logical  recommendations  to  derive  from  the 
study  of  a  legacy  system  clearly  developed  with  outmoded 
methodologies  and  technologies.  Unfortunately,  the  study’s 
authors  chose  to  impute  these  findings  on  every  CPOE  sys¬ 
tem  and  neglected  to  mention  the  aged  nature  of  this  particu¬ 
lar  application — a  fact  that  also  was  not  noted  by  any  of  the 
media  outlets  that  further  promulgated  the  study’s  assertions. 

To  the  further  discredit  of  the  software  engineering  profes¬ 
sion,  this  study  focused  on  the  perceptions  of  system  users 
who  were  unlikely  to  accept  blame  for  their  own  errors  or 
acknowledge  their  own  inadequacies  with  respect  to  using 
the  system.When  the  option  is  to  accept  fault  yourself  or  to 
blame  your  tools,  which  would  you  choose? 

The  State  of  the  Art? 

We  accept  that  in  the  past  the  industry  has  been  sullied  by 
well-publicized  disasters  caused  by  poorly  designed  medical 
software  systems,  most  notably  theTherac-25  debacle.2  But  it 
is  incumbent  on  the  software  engineering  profession  to  both 
publicize  the  advances  that  have  been  made  in  the  past 
decade  and  to  actively  apply  those  advances. 

For  example,  because  the  Eclipsys  CPOE  system  was 
designed  more  than  a  decade  ago,  its  developers  most  likely 
employed  a  waterfall  life-cycle  model.That  the  system  failed 
to  match  the  user  community’s  needs  and  workflow  is,  there¬ 
fore,  no  surprise.3 

Numerous  advances  in  software  engineering  have  thor¬ 
oughly  addressed  the  software  deficiencies  that  the  critics  of 
these  medical  software  systems  discovered.These  advances 
include  the  growth  of  the  subdisciplines  of  requirements 
engineering  (focused  on  the  gathering,  documentation,  and 
analysis  of  user  requirements),  user-interface  design  (focused 
on  the  design  and  construction  of  intuitive  and  safe  user 
interfaces),  and  usability  engineering  (focused  on  the  study  of 
ease  of  use  and  suitability  for  purpose). 

In  addition  to  an  improved  software  engineering  paradigm, 
others  have  identified  the  need  for  better  embedded  medical 
device  user  interfaces  to  reduce  errors.4  We  believe  that 
software  engineers  should  focus  more  attention  on  the 
usability  aspects  of  medical  systems,  whether  they  are  embed¬ 
ded  or  not.The  greatest  risk  in  not  doing  so  are  the  kinds  of 
medical  errors  uncovered  in  studies  that  rightfully  criticize 
the  failure  to  adopt  good  software  engineering  practices.The 
less  obvious  risk,  however,  is  that  failure  to  address  usability 
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elephant,  our  perception  of  the  scope  of  the  application 
of  information  technology  to  healthcare  is  largely  influ¬ 
enced  by  where  we  encounter  the  system.  Virtually  all  of 
us  can  relate  to  issues  associated  with  medical  data 
records  management,  making  it  easier  to  appreciate  the 
Institute  of  Medicine’s  recommendations  for  enterprise- 


level  and  larger  information  systems.  Although  less  vis¬ 
ible  to  the  public,  visions  are  beginning  to  take  shape 
that  are  also  national  in  scope  but  more  focused  on  tech¬ 
nologies  used  in  the  direct  provision  of  care. 

In  “High-Confidence  Medical  Device  Software  and 
Systems,”  Insup  Lee  and  colleagues  describe  a  national 


issues  degrades  the  overall  confidence  that  medical  profes¬ 
sionals  have  in  software  solutions  even  when  an  appropriate 
software  engineering  process  has  been  used  for  all  other 
aspects  of  the  system  except  the  user  interface. 

Ironically,  contemporary  requirements  engineering  tech¬ 
niques  include  many  of  the  investigatory  techniques  employed 
by  physician-researchers  who  study  medical  systems  .Joint 
application  development  employs  focus  groups  of  project  stake¬ 
holders  so  that  each  involved  party  is  represented  in  the 
requirements  elicitation  stage.  Use  case  analysis  employs  user- 
scripted  scenarios  of  interaction  to  ensure  that  the  computer 
system  enforces  a  workflow  and  mode  of  operation  that 
reflects  not  only  the  policies  and  procedures  that  must  be 
met,  but  also  the  ways  of  working  that  the  users  themselves 
favor.  Contextual  inquiry  and  ethnography  involve  user  shadow¬ 
ing  and  observation  so  that  the  analysts  and  developers 
involved  in  constructing  the  information  system  have  a  suffi¬ 
cient  understanding  of  the  problem  domain  to  ensure  that  the 
delivered  application  conforms  with  current  practice  where 
necessary  and  optimizes  current  practices  where  possible. 
Other  techniques  such  as  using  formal  methods  address  the 
issue  of  ensuring  that  the  code  is  correct  and  behaves  accord¬ 
ing  to  the  rules  that  the  healthcare  professionals  determine. 

These  innovations  within  the  software  engineering  commu¬ 
nity  have  been  developed,  or  have  been  more  widely  adopted, 
since  the  deployment  of  many  of  the  medical  systems  that  have 
come  under  criticism.These  techniques  ensure  that  the  deliv¬ 
ered  system  does  all  that  the  users  want  and  need  and  that  the 
correct  checks  and  balances  are  in  place  so  that  human- 
machine  interface  flaws  and  information  errors  do  not  arise. 

Finally,  we  observe  that  many  clinical  systems  currently  in 
use  were  created  prior  to  the  recent,  dramatic  changes  in 
healthcare  delivery.  Integrated  health  networks  with  more 
complex  workflows  and  a  greater  need  for  seamless  move¬ 
ment  of  patient  data  on  demand,  anywhere  within  the  net¬ 
work,  have  for  the  most  part  replaced  free-standing  hospitals, 
clinics,  and  group  practices.  Retrofitting  yesterday’s  systems  to 
meet  today’s  needs  can  only  result  in  a  “solution”  that  falls 
short,  as  the  JAMA  study  clearly  demonstrates. 

Software  engineers  have  long  known  that  extensive  retro¬ 
fitting  causes  software  to  age  very  rapidly.  Considering  what 
we  do  know  about  building  complex  software  systems  and  in 
the  light  of  these  dramatic  changes  in  the  industry,  it  is  unfor¬ 
tunate  that  the  prevailing  sentiment  among  healthcare  profes¬ 
sionals  seems  to  be  that  legacy  information  systems,  their 
developers,  and  their  vendors  are  failing  to  meet  the  needs  of 
physicians  and  hospitals. 


Moving  Forward 

The  message  that  should  be  delivered  is  that  hospital 
administrators  must  push  for  modern  computer  systems 
rather  than  taking  the  cheap  way  out  and  trying  to  adapt 
outdated  technology.  Further,  healthcare  professionals  have  a 
role  to  play  in  the  specification,  validation,  and  deployment  of 
complex  software  systems  such  as  CPOE.The  burden  to 
deliver  correct  and  usable  applications  isn’t  entirely  on  the 
software  engineers  and  software  vendors.  Software  engineer¬ 
ing  professionals  must  be  proactive  in  educating  healthcare 
professionals  about  the  role  they  must  play  in  building  systems 
that  are  responsive  to  their  needs  and  are  reliable  and  safe. 

As  it  turns  out,  several  major  medical  systems  develop¬ 
ers — Eclipsys,  Siemens  Medical  Solutions,  and  McKesson 
HBOC — are  all  located  near  our  campus,  and  some  of  our 
best  students  hail  from  these  companies.Therefore,  we  know 
that,  whatever  the  state  of  affairs  was  1 0  or  20  years  ago,  at 
least  some  representatives  of  the  medical  software  commu¬ 
nity  are  now  applying  state-of-the-art  software  engineering 
techniques  in  the  development  of  medical  informatics  sys¬ 
tems — including  design  for  usability. 

As  a  profession,  we  must  get  the  word  out  to  healthcare 
providers  that  the  state  of  affairs  in  software  engineering  has 
improved  dramatically. 

References 

1 .  R.  Koppel  et  al.,“Role  of  Computerized  Physician  Order  Entry  Sys¬ 
tems  in  Facilitating  Medication  Errors,”  JAMA,  9  Mar.  2005,  pp.  I  1 97- 
1202. 

2.  N.G.  Leveson  and  C.S.Turner,“An  Investigation  of  theTherac-25 
Accidents,”  Computer, July  1 993,  pp.  18-41. 

3.  P.A.  Laplante  and  C.J.  Neill, “The  Demise  of  the  Waterfall  Model  Is 
Imminent  and  Other  Urban  Myths  of  Software  Engineering,”  ACM 
Queue,  Feb.  2004,  pp.  10-15. 

4.  J.  Ganssle, “First  Do  No  Harm:  A  Cry  for  Help  from  a  Hospital  Sys¬ 
tems  Engineer”;  www.embedded.com. 


Phillip  A.  Laplante  is  an  associate  professor  of  software  engineer¬ 
ing  at  Penn  State  University.  Contact  him  at  plaplante@gv.psu.edu. 

Colin  J .  Neill  is  an  associate  professor  of  software  engineering  at 
Penn  State  University.  Contact  him  at  cjn6@psu.edu. 

Raghvinder  Sangwan  is  an  assistant  professor  of  information  sci¬ 
ence  at  Penn  State  University.  Contact  him  at  rxs69@psu.edu. 


April  2006 

page  17 


29 


Appendix 


collaborative  effort  involving  academics  and  profes¬ 
sionals  working  together  to  identify  and  address  the  crit¬ 
ical  issues  presented  by  the  emergence  of  intelligent 
clinical  technologies. 

Vision  meets  reality 

Moving  from  vision  to  product  requires  not  only  atten¬ 
tion  to  good  software  engineering  practices  and  aware¬ 
ness  of  the  regulatory  environment,  but  also  a  grounding 
in  fundamental  risk  management  principles.  Steven  R. 
Rakitin  explores  all  three  in  “Coping  with  Defective 
Software  in  Medical  Devices.” 

Reality  meets  New  Age:  How  can 
we  not  use  agile  methods? 

In  “IGSTK:  An  Open  Source  Software  Toolkit  for 
Image-Guided  Surgery,”  Kevin  Gary  and  colleagues  start 


with  a  description  of  the  critical  requirements  posed  by 
the  needs  of  image-guided  surgery  that,  when  coupled 
with  the  resources  available  to  his  team,  result  in  daunt¬ 
ing  development  constraints.  The  authors  describe  the 
development  and  application  of  a  mixture  of  classical 
and  agile  tools  and  methods  in  support  of  their  clinical 
application. 

Wireless  changes  everything 

In  many  institutions,  it  once  was  easy  to  partition 
medical  and  nonmedical  networked  devices  by 
installing  them  on  physically  distinct  wired  networks. 
That  degree  of  control  effectively  came  to  an  end  with 
the  introduction  of  wireless  medical  device  networks.  In 
“Ensuring  Patient  Safety  in  Wireless  Medical  Device 
Networks,”  Vijay  Gehlot  and  Elliot  B.  Sloane  provide 
an  insightful  view  into  the  risks,  details,  and  nuances 
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Interoperability  Program 


Julian  M.  Goldman,  Massachusetts  General  Hospital 

Jennifer  L.  Jackson,  Brigham  and  Women’s  Hospital 

Susan  F.  Whitehead,  Center  for  the  Integration  of  Medicine  & 

Innovative  Technology 

Tracy  L  Rausch,  Kaiser  Permanente  Mid-Atlantic  States 

Sandy  Weininger,  FDA  Center  for  Devices  and  Radiological 

Health/OSEL/DESE 

A  patient  undergoing  gallbladder  surgery  is  under  general 
anesthesia  during  the  procedure.To  avoid  image  blurring 
while  taking  X-ray  images  during  the  surgery,  it  is  necessary 
to  switch  off  the  ventilator  that  is  breathing  for  the  anes¬ 
thetized  patientTurning  the  ventilator  off,  taking  the  X-ray, 
and  turning  the  ventilator  back  on  again  are  all  manual 
processes.  If  the  team  of  caregivers  is  distracted,  it  is  possible 
that  the  ventilator  might  not  be  turned  back  on. Although 
very  unlikely,  this  tragedy  has  occurred  (www.apsf.org/ 
resource_center/newsletter/2004/winter/03turn_on.htm). 

This  scenario  is  one  of  many  involving  ensembles  of  stand¬ 
alone  medical  devices  in  which  each  acts  as  a  stand-alone 
device,  with  its  only  sources  of  information  coming  from  the 
operator  and  sensors.  If  the  X-ray  machine  and  ventilator 
were  context-aware  and  able  to  communicate  with  one 
another,  synchronization  of  the  X-ray  exposure  to  the  phase 
of  ventilation  could  minimize  the  need  to  turn  off  the  ventila¬ 
tor,  substantially  reducing  the  potential  for  the  disaster 
described  above.The  same  approach  could  improve  image 
quality  and  decrease  wasted  images  and  unnecessary  X-ray 
exposure  when  X-rays  are  taken  in  the  intensive  care  unit. 

But  the  state  of  the  art  with  respect  to  medical  device 
interoperability  is  reflected  in  a  small  number  of  proprietary 
products  that  provide  some  capabilities  geared  primarily  at 
populating  patient  record  systems  and  single-vendor“inte¬ 


grated”  networked  systems.  Despite  almost  20  years  of 
attempting  to  define  standards  that  enable  medical  device 
interoperability,  little  real  progress  has  been  made  in  terms  of 
delivering  solutions  to  the  market,  particularly  for  problems 
involving  emergent,  real-time  patient  care. 

The  absence  of  market-ready  interoperability  solutions  has 
stalled  the  development  of  fully  integrated  electronic  health 
records,  smart  alarms,  real-time  clinical  decision  support  sys¬ 
tems,  and  automated  safety  systems  (with  medical  device  inter¬ 
locks).  As  a  result,  clinicians  cannot  easily  use  technology  to 
enhance  situational  awareness  or  control  devices  in  the  clinical 
environment,  and  they  must  continue  to  rely  instead  on  team¬ 
work  and  a  patchwork  of  systems  to  mitigate  clinical  hazards. 

Inspired  by  successes  such  as  the  Operating  Room  of  the 
Future  (ORF)  program  at  Massachusetts  General  Hospital 
(MGH)  and  driven  as  much  by  frustration  at  not  being  able  to 
provide  the  “latent  opportunities”  of  innovation  in  clinical 
care  that  we  know  modern  technology  could  support,  as  well 
as  by  the  rapidly  changing  economics  and  dynamics  of  the 
patient  care  environment,  we  in  the  user  community  are 
beginning  to  respond. 

In  our  case,  we  have  established  a  program  to  fully  address 
medical  device  interoperability  to  support  the  development 
of  connected,  error-resistant  medical  device  systems  through¬ 
out  the  continuum  of  healthcare.  Over  the  past  two  years,  the 
Medical  Device  Plug-and-Play  Interoperability  Program  (MD 
PnP;  www.mdpnp.org),  founded  by  the  Center  for  the 
Integration  of  Medicine  and  Innovative  Technology  (CIMIT; 
www.cimit.org/orfuture.html)  and  MGH,  has  surveyed  clinical 
groups  representing  leading  surgeons, anesthesiologists, 
nurses,  and  clinical  engineers  to  acquire  the  information 
needed  to  derive  use  cases  and  drive  requirements  defini- 
tions.We  are  converting  selected  clinical  use  cases  into  pro- 
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of  placing  such  a  system  into  service.  They  also  exam¬ 
ine  the  subtleties  driving  the  need  for  hospital-based 
clinical  engineering  involvement  in  system  verification 
and  validation. 

Everything  Changes  FDA 

Cognizant  of  issues  like  the  ones  that  challenged 
Gary’s  team,  regulators  are  faced  with  determining 
how  to  respond  to  issues  that  emerge  with  the 
rapid  evolution  of  software-based  medical  devices. 
In  “A  Formal  Methods  Approach  to  Medical  Device 
Review,”  Raoul  Jetley  and  colleagues  describe  a  set 
of  formal  approaches  for  application  test  and 
validation  during  the  premarket  approval  process 
or  when  doing  a  forensic  analysis  of  problems 
that  occur  after  a  device  has  been  delivered  to  the 
market. 


Indeed,  to  err  is  human.  But  it  does  not  follow  that 
harm  cannot  be  prevented.  Systems  and  software 
engineering  contribute  not  only  to  advancing  and 
improving  the  delivery  of  care  but  also  to  doing  it  more 
safely  than  has  been  the  case  in  the  past.  Doing  so 
appears  likely  to  require  greater  collaboration  between 
manufacturers,  regulators,  and  users  in  the  future.  And 
it  is  happening. 

But  more  needs  to  be  done,  and  soon.  While  the  work 
that  the  IHE  and  MD  PnP  are  doing  makes  many  of  us 
hopeful  that  interoperable  medical  device  systems  will 
soon  begin  to  be  realized,  hard  questions  need  to  be 
asked,  such  as,  Why  did  IEEE  11073  move  so  slowly? 
What  more  needs  to  happen  for  its  vision  to  be  realized 
in  the  market?  What  could  we  do  differently  to  avoid 
similar  inertia  when  tackling  future  systems  and  soft¬ 
ware  engineering  problems? 


totype  models  to  be  implemented  in  our  MD  PnP  Lab  with 
commercially  available  medical  devices. 

The  MD  PnP  Lab  is  implementing  the  gallbladder  imaging 
scenario  as  the  first  clinical  use  case  around  which  to  begin  to 
define,  select,  or  develop  the  processes,  tools,  framework,  and 
components  with  which  to  construct  the  needed  system. 
Throughout  the  MD  PnP  program,  it  is  our  intent  to  reuse 
and  leverage  existing  work  wherever  possible,  and  we  will 
support  the  use  of  currently  existing  consensus  standards  if 
they  can  contribute  to  the  implementation  of  these  clinical 
use  cases.We  are  also  acutely  aware  that  other  significant 
challenges,  such  as  data  security,  liability  and  regulatory  issues, 
network  performance  monitoring,  and  interoperability  with 
the  broader  healthcare  enterprise  must  also  be  addressed. 

The  impetus  for  the  MD  PnP  program  relies  on  both  the 
visionary  and  real  foundation  provided  by  the  ORF  along  with 
the  collaboration  and  extended  vision  of  its  members.The 
ORF,  a  program  of  CIMIT  and  MGH,  is  a  fully  functioning  OR 
suite  in  MGH.The  ORF  serves  as  a  “living  laboratory”  for 
clinicians,  engineers,  technicians,  architects,  and  administrators 
to  study  the  impact  of  process  change,  technology,  and  team¬ 
work  on  safety  and  productivity.The  ORF  also  serves  as  a 
protected  environment  and  aggregation  point  to  develop  and 
safely  validate  and  test  those  ideas,  including  MD  PnP,  that  are 
envisioned  as  necessary  to  lay  the  foundation  for  safety  and 
efficiency  innovations  in  perioperative  healthcare. 

The  MD  PnP  “geographically  dispersed  team”  includes  not 
only  members  of  Partners  Healthcare  clinical,  information 
services,  and  clinical  engineering  staff  but  also  colleagues  from 
other  integrated  healthcare  delivery  networks  (IHDNs)  such 
as  Kaiser  Permanente;  marketing  and  engineering  staff  from 
medical  device  manufacturers;  FDA  and  NIST  staff  involved  in 
the  regulation  and  testing  of  software- based  medical  devices; 
marketing  and  engineering  staff  representing  manufacturers  of 
information  technology-based  hardware  and  software;  and 
members  of  academic  and  research  communities. 


Many  MD  PnP  members  are  also  involved  in  efforts  like  IEEE 
I  1073  and  the  Integrating  the  Healthcare  Enterprise  Initiative 
Domain  for  Patient  Care  Devices  (IHE  PCD)  of  the  Health¬ 
care  Information  and  Management  Systems  Society.  Oppor¬ 
tunities  to  work  together  come  both  at  the  various  standards 
meetings  as  well  as  on  shared  projects  and  problems. 

The  continued  lack  of  automated  safety  systems,  smart 
alarms,  closed-loop  control,  and  decision  support  systems  at 
the  patient  bedside,  coupled  with  the  tacit  acceptance  of 
resultant  risks  that  thereby  accrue,  is  unconscionable  in  the 
presence  of  readily  available  technology  that  is  applied  to 
similar  goals  seemingly  everywhere  but  healthcare.We  in  the 
MD  PnP  program  are  intent  on  addressing  it. 

Julian  M.  Goldman,  MD,  is  the  director  of  the  Medical  Device 
“Plug-and-Play”  Interoperability  Program  in  the  Departments  of 
Anesthesia  and  Biomedical  Engineering  at  Massachusetts  General 
Hospital  and  the  Center  for  the  Integration  of  Medicine  and  Innovative 
Technology.  Contact  him  at  jmgoldman@partners.org. 

Jennifer  L.  Jackson  is  the  assistant  director  of  biomedical  engi¬ 
neering  at  the  Brigham  andWomeris  Hospital,  Boston,  Mass.  Contact 
her  at  jljackson@partners.org. 

Susan  F.  Whitehead  is  the  Medical  Device  “Plug-and-Play” 
Interoperability  Program  project  manager  in  the  Center  for  the 
Integration  of  Medicine  &  Innovative  Technology,  Cambridge,  Mass. 
Contact  her  at  swhitehead@partners.org. 

Tracy  L  Rausch  is  a  clinical  systems  engineer  at  Kaiser  Permanente 
Mid- Atlantic  States,  Rockville,  Md.  Contact  her  at  tracy.rausch@ 
kp.org. 

Sandy  Weininger  is  a  senior  regulatory  engineer,  FDA  Center 
for  Devices  and  Radiological  Health /OSEL/DESE,  Rockville,  Md. 
Contact  him  at  sandy.weininger@fda.hhs.gov. 
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The  involvement  of  experts  from  outside  the  medical 
technology  domain  could  prove  valuable.  For  example, 
researchers  might  be  better  positioned  to  help  us  more 
rigorously  address  emerging  issues  such  as  whether  med¬ 
ical  device  networks  should  merge  with  hospital  or  other 
clinical  information  systems  networks.  And,  jumping 
even  further  outside  the  box,  consideration  needs  to  be 
given  to  how  healthcare-based  engineers,  caregivers,  and 
technologists  can  become  even  more  engaged  in  tech¬ 
nology  definition,  development,  and  design  decisions 
and  activities,  to,  for  example,  address  human  factors 
issues  that  will  likely  increase  with  device  and  system 
complexity. 

Medicine  remains  fundamentally  reactive;  we  wonder 
how  it  can  be  otherwise.  A  person  can  do  everything 
possible  to  remain  healthy,  but  sooner  or  later,  if  an  acci¬ 
dent  doesn’t  strike,  illness  will.  When  this  occurs,  clini¬ 
cians  attending  to  the  patient  remain  driven  by  the  basic 
principle,  “First,  do  no  harm,”  and  they  expect  that  the 
tools  they  use  will  not  permit  their  violating  that  prin¬ 
ciple. 

To  address  patient  safety  in  the  face  of  the  perturba¬ 
tions  that  arise  from  human  error  as  well  as  other 
sources,  proactive  systems  and  software  engineering 
attention  must  increasingly  focus  on  continuously  ere- 
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ating  robust,  reliable,  and  dependable  applications  and 
an  infrastructure  focused  on  addressing  needs  at  the 
point  of  delivery  of  care. 
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Medical  Device  Connectivity  for  Improving  Safety 
and  Efficiency 

Julian  M.  Goldman,  M.D. 

Committee  on  Electronic  Media  and  Information  Technology 


“ Use  wireless  technologies  to  eliminate  the  ‘ malignant 
spaghetti ’  of  cable  clutter  that  interferes  with  patient  care , 
creates  hazards  for  the  clinical  staff  and  delays  positioning 
and  transport  ” 


“Synchronize  the  respiratory  cycle  of  the  anesthesia 
machine  ventilator  with  portable  X-ray  exposure  so  that  an 
X-ray  will  be  triggered  at  end-expiration,  thus  avoiding  the 
need  to  turn-off  the  ventilator  for  an  intraoperative 
cholangiogram.  ” 

“Trigger  the  portable  X-ray  at  end-inspiration  by 
synchronizing  with  the  ICU  ventilator  ” 

“Why  can't  a  pulse  oximeter  be  connected  to  a  PC  A 
infusion  and  automatically  interrupt  the  infusion  and 
activate  an  alarm  when  a  patient  is  hypoxemic?” 

“Support  the  recording  of  infusion  pump  data  in  the 
electronic  anesthesia  information  system  and  permit  control 
of  the  infusion  rate  at  the  anesthesia  machine 


Index 


FEATURES 

Critical  Care  Medicine:  At  the 
Crossroads 

•  The  Opportunity  of  Critical 
Care  Medicine 

•  Perspective  of  a 
Nonintensivist:  Why  Critical 
Care  Medicine  Is  Important 
to  the  Future  of  Our 
Specialty 

•  New  Concepts  in  ACLS 

•  Translational  Critical  Care 
Research  —  Collaboration 
Across  the  Sea 

•  Rapid  Response  Teams: 
The  Role  for 
Anesthesiologists  and 
Anesthesiology-Based 
Intensivists 

•  Changing  Concepts  of 
Transfusion  Triggers: 
Lessons  From  the  ICU 


ARTICLES 

•  Chicago:  Welcome  to  the 
Neighborhood 


News 

Archives 


Links  of 
Interest 


These  are  only  a  few  examples  of  clinical  scenarios  provided  by 
anesthesiologists  to  articulate  their  vision  of  improvements  in 
clinical  care  that  could  be  achieved  by  interconnecting  medical 
devices.1  The  barriers  to  medical  device  connectivity  (or 
“interoperability”)  are  well  known  to  those  anesthesiologists  and 
clinical  engineers  who  have  tried  to  install  anesthesia  information 
management  systems  (AIMS)  or  to  interconnect  devices  and 
computers  for  clinical  research.  In  contrast  to  the  ubiquitous  USB 
memory  devices  that  support  effortless  connectivity  on  all  brands  and 
types  of  modern  computers,  or  the  Internet  browser  programs  and  Web 
sites  that  enable  secure  banking  over  the  Internet,  we  have  not 
implemented  equivalent  secure,  ubiquitous  connectivity  technology  to 
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support  vendor-neutral  medical  device  networks.  As  a  result,  the  cost 
and  complexity  of  seamless  connectivity  is  interfering  with  widespread 
deployment  of  AIMS,  remote  monitoring,  use  of  comprehensive 
(laboratory  +  monitor)  data  to  develop  clinical  decision  support 
systems  and  smart  alarms. 

The  importance  of  interoperability  to  support  improvements  in  health 
care  has  been  underscored  by  the  establishment  of  the  position  of  the 
National  Health  Information  Technology  (HIT)  Coordinator  on  April  27, 
2004,  to  provide  leadership  for  the  “development  and  nationwide 
implementation  of  an  interoperable  health  information  technology 
infrastructure  to  improve  the  quality  and  efficiency  of  health  care.”2 

The  vision  includes  developing  “a  nationwide  interoperable  health 
information  technology  infrastructure  that: 

“2a.  Ensures  that  appropriate  information  to  guide 
medical  decisions  is  available  at  the  time  and  place  of 
care; 

2b.  Improves  health  care  quality,  reduces  medical 
errors  and  advances  the  delivery  of  appropriate 
evidence -based  medical  care; 

2c.  Reduces  health  care  costs  resulting  from 
inefficiency,  medical  errors,  inappropriate  care  and 
incomplete  information;  and 

2d.  Promotes  a  more  effective  marketplace,  greater 
competition  and  increased  choice  through  the  wider 
availability  of  accurate  information  on  health  care  costs, 
quality  and  outcomes.” 

Similarly  the  2005  Institute  of  Medicine  Report,  Building  a  Better 
Delivery  System:  A  New  Engineering  /Health  Care  Partnership, 
emphasizes  the  need  for  a  National  Health  Information  Infrastructure 
“to  support  the  information-driven  practice  of  contemporary  medicine. 
This  infrastructure  would  consist  of  standards  for  connectivity,  system 
interoperability,  data  content  and  exchange,  applications  and  laws.”3 

The  absence  of  effective  medical  device  connectivity  has  been  due  in 
part  to  an  absence  of  implemented  open  standards,  the  lack  of 
financial  incentives  for  device  manufacturers  to  provide  systems  to 
support  vendor-independent  connectivity,  legal  and  regulatory 
concerns  and  unclear  clinical  specifications  —  or  “clinical 
requirements”  — for  the  proposed  systems. 

The  national  HIT  agenda  includes  making  the  interoperability  of 
electronic  health  care  records  (EHR)  a  reality,  but  we  are  concerned 
that  EHRs  will  be  neither  complete  nor  accurate  until  the  inclusion  of 
medical  device  data  is  automated. 

There  are  two  distinct,  and  closely  related,  facets  of  medical  device 
interoperability: 

•  Data  communication  standards  will  support  accurate 
data  acquisition  by  the  EHR  from  monitors,  infusion 
pumps,  ventilators,  portable  imaging  systems  and  other 
hospital  and  home-based  medical  devices.  Reliable 
data  will  support  complete  and  accurate  EHRs  and 
robust  databases  for  continued  quality  improvement 
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use. 

•  Medical  device  control  standards  will  permit  the 
control  of  medical  devices  to  produce  “error-resistant” 
systems  with  safety  interlocks  between  medical  devices 
to  decrease  use  errors,  closed-loop  systems  to  regulate 
the  delivery  of  medication  and  fluids  and  remote  patient 
management  to  support  health  care  efficiency  and 
safety  (e.g.,  remote  intensive  care  unit,  management  of 
infected/contami  nated  casualties) . 


The  Medical  Device  Plug-and-Play  (MD  PnP)  program  was  initiated  in 
May  2004  at  the  Center  for  Integration  of  Medicine  and  Innovative 
Technology,  or  CIMIT,  and  Massachusetts  General  Hospital  to  identify 
and  implement  connectivity  standards  while  ensuring  that  they  remain 
clinically  grounded  <www.mdpnp.org>.4’  5  The  program  has  convened 
diverse  stakeholders  (clinicians,  the  Food  and  Drug  Administration, 
manufacturers,  biomedical  and  clinical  engineers,  clinical  societies  and 
others)  to  develop  a  roadmap  for  open-standards-based,  vendor- 
neutral  medical  device  interoperability.  The  early  identification  of  the 
importance  of  basing  interoperability  solutions  on  clinical  requirements 
led  us  to  begin  compiling  the  unique  body  of  clinical  requirements 
represented  in  the  examples  above.  The  clinical  requirements  were 
elicited  from  clinicians  and  engineers  who  were  asked  to  provide 
examples  of  connectivity  that  could  a)  solve  current  clinical  problems, 
b)  improve  safety  or  efficiency  or  c)  enable  innovative  clinical  systems 
of  the  future.  A  major  goal  is  to  identify  potential  solutions  to  perceived 
shortcomings  of  current  clinical  practice  or  ideas  for  future  innovations 
that  require  improved  interoperability  for  implementation.  The  MD  PnP 
Lab,  scheduled  to  open  in  the  second  quarter  of  2006,  provides  a 
vendor-neutral  environment  in  which  to  evaluate  the  feasibility  of 
implementing  some  of  these  clinical  scenarios,  including  evaluating 
connectivity  products  and  standards  as  they  are  developed.  The  Lab 
thus  provides  the  protected  environment  that  will  enable  latent 
opportunities  for  improving  patient  safety  to  be  explored  and  realized. 

We  will  hold  an  open  session  at  the  ASA  2006  Annual  Meeting  in 
Chicago  to  gather  your  clinical  requirements  for  inclusion  in  the  master 
requirements  list,  which  will  guide  national  solutions.  Feel  free  to  get 
started  now  by  sending  your  ideas  to  us  at  <asa@mdpnp.org>  or 
posting  your  ideas  and  initiating  discussion  on  the  discussion  area  of 
<www.mdpnp.org>  (free  registration  required  to  post  information). 
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